Adds a Sinks section, the counterpart of the existing Sources section, closing the sink-side gap deferred in #32 ("active versus passive sinks, and downstream-destination trust").

The section states three things:

1. Sinks are the destinations an appender writes to. Unlike sources, which range from trusted configuration to untrusted content, every sink is operator-configured and therefore trusted, including destinations created dynamically at runtime (for example a Routing appender that interpolates a file path).

2. Destination integrity is a deployer responsibility. An adversary who can write to a log destination, for example by planting a symbolic link where a file appender creates its output, can already tamper with the logs directly, so the frameworks do not defend a destination they were configured to trust. A report that assumes such write access is out of scope.

3. A passive sink consumes our output as the format the layout produced, and we own the correctness of that format. An active sink re-interprets well-formed output in another language and acts on it (a terminal executing ANSI escape sequences, for example), which we do not own. The boundary is whether the framework emitted output malformed in its own format (ours to fix) or well-formed output that a sink chose to re-interpret (out of scope).

The two worked examples are precedents: CVE-2025-54812 (Log4cxx HTML layout emitting malformed HTML) is a defect we published, while the class of CVE-2025-55754 (Apache Tomcat, ANSI escape sequences interpreted by a Windows console) is one we do not treat as a vulnerability.

Dependent edits: the Log Injection threat now lists the HTML layout and cross-references the passive/active distinction; the out-of-scope adversary list adds the destination-write-access case and the active-sink re-interpretation case.

This is normative and requires PMC review before merge.

Assisted-By: Claude Opus 4.8 <noreply@anthropic.com>